QRZ! Ham Radio 5/QRZ Ham Radio Callsign Database - Volume 5.iso/digests/digital/940105.txt

Internet Message Format | 1994-11-13 | 19.3 KB

Date: Sat,  9 Apr 94 04:30:25 PDT
From: Ham-Digital Mailing List and Newsgroup <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Ham-Digital Digest V94 #105
To: Ham-Digital


Ham-Digital Digest          Sat,  9 Apr 94       Volume 94 : Issue  105

Today's Topics:
                    Difference: 1270B and 1270C??
                    FCC Packet Message Forwarding
              Is KA9Q telnet correct? (virtual terminal)
                       NTS---Hank Oredson notes
                         RTTY for a beginner.
                        sexually explicit talk
                      TCP/IP <--> FBB ax.25 link
                    TCP/IP from car w/PK-88 (Help)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Ham-Digital Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Wed, 06 Apr 1994 12:56:32 +0600
From: ihnp4.ucsd.edu!galaxy.ucr.edu!library.ucla.edu!agate!howland.reston.ans.net!math.ohio-state.edu!news.acns.nwu.edu!ftpbox!mothost!delphinium.cig.mot.com!mac-am-14.cig.mot.com!user@network.
Subject: Difference: 1270B and 1270C??
To: [e-mail]

What is the difference between the MFJ 1270B and the "new" 1270C?

Thanks,

Marc Holdwick - N8KWX

------------------------------

Date: 08 Apr 1994 16:03:22 GMT
From: pa.dec.com!nntpd.lkg.dec.com!nntpd.bb.dec.com![e-mail]
Subject: FCC Packet Message Forwarding
To: [e-mail]

    But what constitutes "atuhenticating" the source station?
--
--
Bill Freeman, [e-mail], KE1G, PP-SMEL-IA(ME VFR only) N4365Z
USABDA, MassABDA (novice modern), NMRA, rounds, squares, bad jokes.
Telemarketing: Do more than just say no, write saying you seek other vendors.

------------------------------

Date: Thu, 7 Apr 1994 20:34:23 +0000
From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!pipex!uknet!demon!llondel.demon.co.uk![e-mail]
Subject: Is KA9Q telnet correct? (virtual terminal)
To: [e-mail]

Try looking at the 'eol' command on KA9Q. I think there is some trickery
involved to switch from the DOS newline to the Unix newline convention
(similar to transferring ASCII files via ftp) which might even be done with
some negotiation when opening the telnet connection. Possibly some flavours
of software do it better than others?

Dave
--

*****************************************************************************
* G4WRW @ GB7WRW.#41.GBR.EU AX25     *    Start at the beginning. Go on     *
* [e-mail]  Internet *     until the end. Then stop.        *
* [e-mail]      Amprnet  *      (the king to the white rabbit)  *
*****************************************************************************

------------------------------

Date: Fri, 8 Apr 1994 14:10:34 GMT
From: elroy.jpl.nasa.gov!swrinde!emory!wa4mei!ke4zv![e-mail]
Subject: NTS---Hank Oredson notes
To: [e-mail]

In article <[e-mail]> <[e-mail]> writes:
>Hank, an old time friend from the Twin Cities now in "exile" in Oregon
>said about the BBS/NTS interface:
>>
>>'But in any case, stop trying to force fit things that were appropriate
>>40 or more years ago to the present reality.'
>>...
>>
>>   ...  Hank
>
>Of course Hank is right about this. The "regular" NTS, something Hank and I
>and many others participated in years ago, was and is a training ground to
>learn message handling in a format useful in emergencies and for military
>use.
>
>The problem is, the telephone is so ubiquitous and so low cost, that
>handling messages that may or may not get delivered rates right up there
>with exchanging re-tries on HF packet. (STA or otherwise).
[snip]
>Forty years ago the communications world was different and the choices
>available and the choices made were different too! Our current culture
>really does not lend itself to the classic NTS format and activity and, as
>a result, we probably can expect it to gradually fade away.
>
>If you have thoughts on where we may be evolving to I would very much like
>to hear them.

As much as I would like to see amateur radio continue to provide useful
message handling systems for emergencies, Mr. Olson is right, our methods
and modes are obsolete in the modern world, except in very rare and limited
cases. If we are to be of help in this arena, and I think we still can be,
then we have to rethink our approach.

For those of us interested in digital modes, the challenge is to seamlessly
internetwork with the "information superhighway". The NTS message format
is not compatable with that goal because it was intended to be handled
with human interpretation and human intervention. We need to re-examine
the way we handle messages, and the format in which they are cast.

Key areas we need to examine are format, addressing, routing, and assured
delivery. RFC822 or X400 messaging standards give us frameworks for messages
that can transparently move over many disjoint networks. The ticklish problems
we face are in resolving a message addressee to a machine address, and in
dynamically building routing systems that can deal with our often transient
systems and links. (We should be able to act as bridges across broken
commercial links in time of emergency without having to handle messages
by hand, and we should be able to utilize commerical networks for part
of our delivery system, again without need of by hand manipulation.)

Because of the disjoint nature of our networks, and because realtime
connectivity across the networks is a rare thing, we can't depend on a
level 4 transport protocol like TCP to meet our end to end message handling
needs, though it's useful in assuring delivery across intermediate connected
segments of the networks. Nor can we use IP to route our messages because
there's no dynamic route building mechanism in current implementations that
can handle transient connectivity and the dynamic message addressee to
destination machine address mapping we require, though we can use IP across
connected segments of the networks while forwarding our messages.

But messages of the types we're considering are at a higher level of
abstraction than is addressed by TCP/IP. That's where the BBS and it's
Sysop have tried to fill the gap. Instead of sending and receiving packets,
the BBS sends and receives whole messages. Instead of resolving packet
addresses and developing dynamic packet routes, the BBS must resolve
message destination address mappings, and develop dynamic message delivery
routes. (SMTP is a method that does this, but it can't cope with the disjoint
nature of our amateur networks.)

It's the same idea as what TCP/IP does on the packet level in semi-realtime,
so we can apply many of the concepts developed for TCP/IP in our message
handling systems. But there are significant differences too. Mainly because
we can't expect timely end to end response, we have to alter the way we
do name service resolution of addresses, and because of the disjoint store
and forward nature of the network segments, we have to change the way
we guarantee end to end integrity and delivery.

The one thing we can't do is allow copies of messages to be diverted
to alternate delivery systems in mid-stream. Daniel gave us a way to
kill duplicates at a destination machine, so having duplicates circulating
inside our networks isn't a serious concern. For example we could try a
flood algorithm in order to insure rapid delivery of a priority message
to a destination machine. Daniel's mechanism of message hashes would
kill later arriving duplicates. But if we allow the messages to be
visible at intermediate machines, they can be diverted to alternate
delivery mechanisms, such as voice, RTTY, or CW NTS nets. And subsequently
delivered, or reinserted into the packet system in a form that defeats
hash checking, or with altered routing to a different destination machine,
so that they are taken and delivered again.

So my first concrete suggestion to the BBS authors is to make NTS
messages invisible to potential NTS traffic takers on intermediate
machines. My second concrete suggestion is that NTS messages on
destination machines should auto-kill when the user who downloads it
logs off the system, and an automatic service message be generated back
to the originating BBS listing the call of the user taking the traffic.
NTS users must be educated that if they download a piece of NTS traffic,
they have then accepted responsibility for delivering that traffic.
(Note, it would be nice if there were an "oops" command so that a
mistakenly downloaded message could be re-enabled on the BBS if the
user decides before logging off that he can't handle it after all.)

>Tod Olson, K0TO
>ARRL Director, Dakota Division

Unrelated note: It's very refreshing to see a Director actively
participating here. Welcome!

Gary
--
Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary
Lawrenceville, GA 30244     |                     |

------------------------------

Date: Thu,  7 Apr 94 18:57:00 -0800
From: ihnp4.ucsd.edu!usc!elroy.jpl.nasa.gov!netline-fddi.jpl.nasa.gov!nntp-server.caltech.edu!news.claremont.edu!kaiwan.com!ledge![e-mail]
Subject: RTTY for a beginner.
To: [e-mail]

Yes, RTTY is usually FSK or AFSK.  The common frequency shifts are
170 Hz (current) and 850 Hz (somewhat obsolete).  It uses a 5 bit
Baudot code, the details of which are in most ARRL handbooks.  As a
matter of fact, you would do well to pick up a copy and see what's
in there on the subject; at least the older books had a good
description.  73 DE K6DDX

------------------------------

Date: 8 Apr 1994 11:19:35 +0100
From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!uknet!acorn![e-mail]
Subject: sexually explicit talk
To: [e-mail]

In article <[e-mail]> [e-mail] (Jeffrey D. Angus) writes:
>In article <[e-mail]> [e-mail] writes:
>  > I don't have a liscense, but I bought a ham radio recently and was thining
>  > about opening sexually explicit gay chatline through info packets over the

etc ..

It seems such a shame to leave out the people from the two remaining
flamethreads, so how about encrypting the traffic and sending it CW ?

-adrian

:-).

------------------------------

Date: Fri, 8 Apr 1994 12:54:24 GMT
From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!math.ohio-state.edu!jussieu.fr!univ-lyon1.fr!swidir.switch.ch!news.unige.ch!ugun2a![e-mail]
Subject: TCP/IP <--> FBB ax.25 link
To: [e-mail]

In article <[e-mail]>, [e-mail] writes:
> Re: Subject: TCP/IP-f6fbb (ax25) link, how do you do it ?
>
> Daniel writes:
>
>>Would anybody know how to manage forward between a tcp/ip STATION
>>and a f6fbb BBS without being declared as a BBS (eg, when you send out
>>to the f6fbb BBS the command sp xxxxx < hb9vbc @ hb9vbc, it immediately
>>advises the sysop and tells you that they don't forward to hb9vbc bbs!)
>>Where does this have to be fixed ?
>
> Sending SP ZL4ABC < ZL4DEF @ ZL4GHI to an FBB BBS results in an msg labelled
> like this:
>
>   Message Choice - [*]
> Msg #  TSL  Size To    @BBS    From   Date/Time     Subject
> ------ ---  ---- ------ ------ ------ -----------   ----------------------
> 25493  PNL     0 ZL4ABC@ZL4GHI ZL4DEF 940401/00:58  TEST
>
> As you have discovered, unless the FBB has a forwarding path set for the
> @BBS, then it goes nowhere and the sysop gets a msg.
>
> Posting the same SP on a JNOS station produces a msg for ZL4ABC on that
> JNOS station, with the msg being labelled as coming from ZL4DEF@ZL4GHI.
>
> If you could state your intent in posting that address format to an FBB, more
> useful help may be possible.
>
Yes, I would exactly like to do that, automatically from NOS.  Send the
fbb bbs a message with the from BBS that has the same address as that fbb
BBS.  Example:  I'm a NOS user, so I would be declared hb9vbc @ hb9vbc.ampr.org
I also use an AX25 BBS called hb9iap.srom.che.eu, so I would like to smtp
the ax25 bbs and tell NOS to use instead of the form sp xxx < hb9vbc @ hb9vbc
the form : sp xxx < hb9vbc @ hb9iap.  Is this possible ???

--
    __
   /// Daniel Pfund                       Internet: [e-mail]
__///  University of Geneva, Economics   AX25: [e-mail]
\\\/   only AMIGA makes it possible !                  ham radio amateur

------------------------------

Date: Fri, 8 Apr 1994 12:46:09 GMT
From: ihnp4.ucsd.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com![e-mail]
Subject: TCP/IP from car w/PK-88 (Help)
To: [e-mail]

Andrew J. Doane ([e-mail]) wrote:

: I have just recently purchased a laptop, and since I have a PK-88 here
: I have not used for a year or so, already have a 50w VHF radio in the car
: that doesn't get much use (I'm a UHF nut), and I already have a TCP/IP
: address allocated to me, I would like to use TCP/IP from the car.

Andrew,

(This has nothing to do with TCP/IP.)

I thought that I was nuts for running CW from the car :-)

And now back to your normal thread.

Good luck,

Smitty, NA5K/m

--
-----------------------------------------------------------------------
| Henry B. Smith - NA5K                             [e-mail] |
| Dallas, Texas                                                       |
|                                                                     |
|        "I'm not sure I understand everything that I know"           |
-----------------------------------------------------------------------

------------------------------

Date: Thu, 7 Apr 1994 20:31:19 +0000
From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!uknet!demon!llondel.demon.co.uk![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <2nupb4$[e-mail]>uk
Subject : Re: TNET-X1J

In article <2nupb4$[e-mail]> [e-mail] (Bill Gunshannon) writes:
>There was talk a while back about someone working on a version of TNET-X1?
>that would work in the DR-200.  Has this ever been done??
>
That was me.... I have the source, I even have a DR200 but trying to get hold
of a Z80 C compiler which will do the necessary tricks for overlays etc to get
the code to fit is not proving quite so easy. I daresay if I spent enough
money I could get a commercial offering capable of doing it but it would be
a lot of money for a one-off project. I did try the public-domain Hitech C
(running under a CP/M emulator on my PC) but that won't do the necessary
tricks. I haven't found a decent Z80 cross-compiler for the PC yet so I am
open to suggestions.

Dave
--

*****************************************************************************
* G4WRW @ GB7WRW.#41.GBR.EU AX25     *    Start at the beginning. Go on     *
* [e-mail]  Internet *     until the end. Then stop.        *
* [e-mail]      Amprnet  *      (the king to the white rabbit)  *
*****************************************************************************

------------------------------

Date: 7 Apr 1994 17:19:10 GMT
From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!sunic!psinntp!psinntp!news.mentorg.com!hpbab33.mentorg.com!wv.mentorg.com![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>ko
Reply-To : [e-mail]
Subject : Re: NTS traffic on packet

In article <[e-mail]>, [e-mail] (Daniel T Senie) writes:
|> In article <[e-mail]> [e-mail] (Dave Kinzer) writes:
|> >In article <[e-mail]> [e-mail] (Daniel T Senie) writes:

|> Actually, the need for rescuing is a BIG problem, and indicates a failure
|> in the network. At least SOME of the BBS systems show the NTS traffic as
|> listable on EVERY node it passes through, for the duration of the stay
|> at that node. If this were not the case, and a link between nodes were
|> down (or the BBS at the other end of the link is down) then the NTS message
|> would be delayed, and not be visible to any user, until the link or distant BBS
|> returned. This would result in a delayed NTS message, with NO confirmation
|> or information to the originator that the message is not getting through.

Sounds to me like some NTS folks need to talk to the BBS sysops involved,
and give them some guidelines on how NTS would like it's traffic handled
within the BBS network.  I would expect NTS to contact me (as well as the
other BBS authors) about these issues; they have not done so.

|> The skepticism on the part of many NTS operators comes from the need to
|> trust a distributed system of unknown (at the moment of sending) reliability
|> to get the message through.

Have there been major problems? Does the NTS liason who takes the message
and delivers it notify the NYS liason who put it into the BBS network? If
they do, what sorts of problems are seen?

At least in this area of the country, I hear a lot of whining from the NTS
folks, but when I look at my own BBS system I see *all* NTS traffic
clearing within 24 hours - to any part of the US and CANADA.  The only
traffic that remains "stuck" is traffic destined to my local area.
Sometimes no NTS liason checks the BBS for several days.

|> I use packet nearly every day to communicate with folks, but often will
|> ask when on a voice mode if they got the message or not.
|>

Why not ask on packet?
The SR command is not really all that hard to type.

|> As noted above, it is not "temptation" that causes trouble. If an intermediate
|> BBS allows a user to list the traffic, and to KILL the traffic, then that
|> user has assumed responsibility for the message. It does not matter if the
|> message gets to the "right" BBS near the destination zip code, just so long
|> as SOMEONE is able to pick it up, and kill it, and have that ONLY HAPPEN
|> ONCE!

And if there is any doubt about who took the traffic from the BBS system,
the BBS log files can confirm who took it, when they took it, etc.

If NTS wants confirmation of the point of exit from the BBS system, a
simple SR and message with "I took your number xxx" is all that is
required.

   ...  Hank

--

Hank Oredson @ Mentor Graphics
Internet     : [e-mail]
Amateur Radio: [e-mail]

------------------------------

End of Ham-Digital Digest V94 #105
******************************